The world is comprised of a wide and varied assortment of environments and subsystems. Akin to the proverbial butterfly flapping its wings in China and causing a hurricane over Texas, miniscule changes to one part of an environment may have catastrophic ripple effects in a distant part of the same environment. To anticipate these effects, it is helpful to study the ramifications of a change before it occurs, and to study these ramifications it is useful to create a model of the environment. This model can then be used to discover the consequences of a change, and the combinatorial effects of multiple alterations to the environment. Additional benefits of such a model are rationalization of the technology portfolio, and assessment and management of various regulatory and business continuity risks.
However, because of the varied nature of their composition, many types of environments do not lend themselves to modeling. A microcosm of this problem occurs in many enterprise architectures. These enterprise architectures may be intended to have a wide variety of uses: disseminating information about goods and services offered through a site on the World Wide Web, achieving objectives related to a business concern, providing a programming infrastructure for development of software, or keeping track of sales and sales force information.
Consequently, these enterprise architectures grow organically, sewn together in a Frankenstinian manner from a variety of heterogeneous machines and applications. Predicting the effects of business initiatives process and organization, the interaction of application, infrastructure and data organization within an IT environment etc. on these enterprise architecture is almost an exercise in futility without some sort of model. However, modeling these types of enterprise architectures is a daunting prospect.
Typically, there are two approaches to creating models for these enterprise architectures. The first is to create a diagram or a spreadsheet based inventory of the items of interest. This approach is problematic, creating these models requires an in depth evaluation of an enterprise architecture and manual creation of the documents, and whole document retention systems must be kept in place to version and store the documents associated with these types of models. Additionally, changes to the enterprise architecture wreak havoc on these models. The effects from these changes must be manually traced through each of the diagrams, which are not only particularly prone to errors, but time consuming as well. Other problems with storing these models in documents include that there may be a large number of users who need to be able to access and modify these documents, and documents of this type don't lend themselves to concurrent modification, and that it is very difficult to cross-reference information across these documents.
The second approach, equally problematic, is to store items of interest within an enterprise architecture in a relational database. Models created with these relational database tables, however, are particularly susceptible to changes in the enterprise architecture itself. Adding layers, applications, dependencies, projects, geographical locations etc. to an enterprise architecture may require changes to the table schema implementing the model, which may in turn may entail revising all the SQL statements used to implement the database.
A microcosm of these problems occurs with respect to determining the importance of a particular asset to the environment. The importance of an asset within an enterprise architecture may go beyond the direct functionality of that asset. In many cases, the importance of an asset depends on the number of other assets that, in turn, depend on that asset. In other words, the importance of an asset relates directly to the impact that removal or downtime of that asset would have on the enterprise architecture should that asset be removed or no longer available. More specifically, the removal of a particular asset may cause ripples of changes which propagate to portions of the enterprise architecture not directly dependent or related to that particular asset.
Typically, solutions to determining the impact of an asset in an environment do not take into account these multiple direct, and indirect, dependencies. Prior solutions to calculating the impact of an asset utilized standard financial tools, such as spread sheets or other tabular recording or calculating means. These solutions are incapable of accounting for the complex interdependencies between assets of a large enterprise architecture. Additionally, these solutions are limited to a single-level dependency and could not formulate an analysis which reflected the impact the removal of a particular asset would aggregately have on an environment.
As can be seen, a need exists for methods and systems for a data model which can model an arbitrarily complex enterprise architecture, and which is easily extensible to allow the representation of any desired logical or physical entity and the associations and dependencies between these entities. Furthermore, a need exists for methods and systems which can use these data models to determine the impact of an asset within the modeled enterprise architecture.